AWS入門ブログリレー2024〜AWS IAM編〜

コンバンハ、千葉（幸）です。

当エントリは弊社AWS事業本部による『AWS 入門ブログリレー 2024』の32日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、 今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2024 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合いいただければ幸いです。

では、さっそくいってみましょう。今回のテーマは『AWS Identity and Access Management (IAM)』です。

このブログで説明すること

今回のテーマである AWS IAM は、かなり広い範囲をカバーするサービスです。全部を詳細に書こうとすると膨大な量になってしまうため、今回は以下に絞って説明します。

• AWS リソースとは何か
• AWS API リクエストを実行するとはどんなことか
• AWS IAM はどのように働くのか
• AWS IAM ロールとはどんな使い方ができるか

少し抽象度が高めの内容です。以下のような具体的な事柄は取り上げません。

• IAM ユーザー/グループ/ロール/ポリシー設計
• マルチアカウント構成における IAM 設計
• IAM ポリシーのチューニング
• AWS IAM Identity Center
• AWS IAM Access Analyzer

AWS IAM とは

AWS IAM は AWSリソースへのアクセス制御をするサービスです。平たく一部分を切り取って言うと、AWSを利用する上でのユーザーや権限の管理をするサービスです。

AWS IAMとは何か、を理解するためには「AWSリソースとは何か」「AWSリソースへのアクセスとは何か」の理解が不可欠ですので、先にそちらを説明します。

AWS リソースとは

AWS を利用するために、利用者は AWS アカウント上にリソースを作成していきます。

リソースは何らかのサービスに属するオブジェクトです。例えば以下が挙げられます。

• EC2 サービスのリソース
  • EC2 インスタンス
  • EBS ボリューム
  • Elastic ネットワークインターフェース
• RDS サービスのリソース
  • DB インスタンス
  • DB パラメータグループ
  • DB スナップショット
• ELB サービスのリソース
  • ALB 用のリスナー
  • ALB 用のロードバランサー
  • ALB/NLB 用のターゲットグループ

AWS リソースは一意の Amazon リソースネーム（ARN）を持ちます。ARN は以下の要素から構成されます。

要素	説明	例
パーティション	AWSリージョンのグループ	aws
サービス	AWSサービスの名前空間	ec2
リージョン	リージョンコード	ap-northeast-1
アカウントID	AWSアカウントID	123456789012
リソースタイプ	リソースのタイプ	instance
リソース識別子	リソースを識別するためのID/名前/パス	i-0abcdef1234567890

上記の要素から構成される ARN の例は以下です。

• EC2 インスタンス：arn:aws:ec2:ap-northeast-1:123456789012:instance/i-0abcdef1234567890
• VPC：arn:aws:ec2:us-east-1:123456789012:vpc/vpc-0e9801d129EXAMPLE
• IAM ユーザー：arn:aws:iam::123456789012:user/johndoe
  • ※ awsパーティションの IAM のリソースの ARN にはリージョンコードが含まれません

AWS リソースは ARN によって全世界の中で一意に特定できる、ということを覚えておきましょう。

参考：Amazon リソースネーム (ARN) - AWS Identity and Access Management

AWS リソースへのアクセスとは

ここでの AWS リソースに対してのアクセスとは、AWS リソースを対象とした AWS API リクエストを実行することを指します。

一例として以下があります。

• EC2 インスタンスを作成する（ec2:RunInstances）
• RDS DBインスタンスを停止する（rds:StopDBInstance）
• ALB のターゲットグループにターゲットを追加する（elasticloadbalancing:RegisterTargets）

AWS リソースへのアクセスには、ec2:RunInstancesなどのアクションが含まれます。

一方で、以下のようなものはここでの「AWS リソースへのアクセス」に該当しません。

• EC2 インスタンス上で OS ユーザーを作成する
• DB インスタンス上でホストされる DB に接続し、テーブルを作成する
• ALB の DNS 名を対象に curl で HTTPS アクセスを実施する

「EC2 インスタンスを作成する」「EC2 インスタンス上で OS ユーザーを作成する」はどちらも EC2 インスタンスに関連した操作であると言えますが、両者を分けて考える必要があります。

AWS サービスのコントロールプレーンとデータプレーン

AWS リソースへのアクセスかどうか、言い換えれば AWS API リクエストの実行であるかどうかを考えるために、コントロールプレーンとデータプレーンを意識してみましょう。

ほとんどの AWS サービスはコントールプレーンとデータプレーンから構成されます。多くの場合、サービスごと、リージョンごとに分かれて構成されています。EC2 などのゾーンサービスは、より細かくアベイラビリティゾーン単位まで分かれて構成されます。

参考：ゾーンサービス - AWS 障害分離境界

コントロールプレーンとデータプレーンのイメージは以下です。

コントロールプレーンは、AWS リソースに対するリクエスト（作成、読み取り/表示、更新、削除、リスト）を受けつけ、コントロールする役割を持ちます。

利用者がコントロールプレーンにアクセスするためには、サービスのエンドポイントを宛先にします。

サービスのエンドポイントには例えば以下があります。

• 東京リージョンの EC2 のサービスエンドポイント：ec2.ap-northeast-1.amazonaws.com
• 大阪リージョンの S3 のサービスエンドポイント：s3.ap-northeast-3.amazonaws.com
• IAM のサービスエンドポイント：iam.amazonaws.com
  • ※IAM の場合、サービスエンドポイントがリージョンごとに分かれていません

コントロールプレーンが新規の EC2 インスタンスの作成リクエストを受け取るとします。そうすると、以下のようなタスクを実行します。

• 配置グループと VPC のテナント要件を尊重しながら、コンピューティング用の物理サーバーを見つける
• VPC サブネットからネットワークインターフェイスを割り当てる
• Amazon Elastic Block Store (EBS) ボリュームを準備する
• AWS Identity and Access Management (IAM) ロール認証情報を作成する
• セキュリティグループルールを設定する
• 結果をさまざまなダウンストリームサービスのデータストアに保存する
• 必要に応じて、VPC サーバーとネットワークエッジに必要な構成を伝播する

  アベイラビリティーゾーンを使用した静的安定性より

コントロールプレーンによる上記の働きによって、データプレーンに EC2 インスタンスが作成されます。

データプレーンでは EC2 インスタンスが稼働し、パケットのルーティング、EBS ボリュームからの読み書き、その他もろもろの OS 以上の働きが実行されます。

ここでは EC2 を例に取りましたが、RDS でも ELB でも S3 でも IAM でも、それぞれのサービスに応じたリソースがデータプレーン上で稼働し、自身の働きを行います。

AWS リソースに対するアクセスの制御とは

ここまで見てきたような「AWS リソースへのアクセス」、言い換えれば AWS API リクエストの実行には当然権限が必要です。どこかの誰かが勝手に自分の EC2 インスタンスの設定変更ができてしまっては困ります。

そういった「誰が」「何に対して」「何を実行できる」を制御するのが AWS IAM の役割です。

AWS IAM に関する用語の定義

AWS IAM にはさまざまな用語が登場します。以下のあたりを整理しておきましょう。

• IAM リソース
• IAM アイデンティティ
• IAM エンティティ
• プリンシパル
• ヒューマンユーザー（ヒューマンアイデンティティ）
• ワークロード

参考：IAM の仕組み - AWS Identity and Access Management

上記のページを参考に、全体像を表す絵を描きました。便宜上、番号を振っています。

1. IAMリソース

IAM サービスに属する AWS リソースを指します。IAM サービスのデータプレーン上で機能します。

IAM ユーザーや IAM ポリシーといった有名なものから、MFA（MFAデバイスそのものではなく、AWSリソースとしての MFA を指します。） といったものまであります。全量を確認したい方は、以下からどうぞ。

参考：AWS Identity and Access Management (IAM) のアクション、リソース、および条件キー - サービス認証リファレンス

2. IAM アイデンティティ

IAM ユーザー、IAM ロール、IAM グループを指します。平たく言うと、IAM ポリシー（アイデンティティベースポリシー）をアタッチできるものです。

これらを指して「プリンシパルエンティティ」「IAM プリンシパル」と表現されることもあります。ややこしいです。

3. IAM エンティティ

ここでは、IAM ユーザーと IAM ロールを指します。認証に使用できる IAM リソースのことを表します。

IAM ユーザーの場合は主に永続的な認証情報（パスワードもしくはアクセスキー）が、IAM ロールの場合は一時的な認証情報（一時的なアクセスキー）が取得できます。 ^*1

IAM グループが IAM エンティティに含まれないのは、IAM グループを使用しての認証はできないからです。IAM グループはあくまで IAM ユーザーにまとめて IAM ポリシーの設定を配布するための箱であり、「IAM グループAとしてアクションを実行する」ということはできません。

エンティティってなに？

エンティティとは、「実体」という意味を持ちます。この後出てくる「ヒューマンユーザー」「ワークロード」は AWS の世界には実体を持たず、IAM エンティティを通じて AWS リソースへのアクセスを行います。そのため、IAM エンティティは IAM ユーザーと IAM ロールのことを指す、とする文脈が多いです。

一方で、AWS リソースは AWS の世界に実体を持っていると考えることもできます。例えば、IAM リソースとしての MFA は以下のように ARN を持ちます。

arn:aws:iam::123456789012:mfa/MFA名

AWS リソースのことを指してエンティティと呼ぶ文脈もあります。つまり IAM エンティティが IAM リソースと同じ意味で使われることもあります。

特定の定義にとらわれず、その言葉が何を指すかは文脈から判断するようにしましょう。

4. プリンシパル

このあたりはちょっとややこしいです。プリンシパルを考えるために、まずは「ヒューマンユーザー」「ワークロード」のことを考えます。両者ともに、AWS の世界では実体を持たないものです。

ヒューマンユーザー

要は人間のことを指します。「人間ユーザー」と書こうと思ったのですが、ちょっと圧が強いのでやめました。

単に「ユーザー」と書くと IAM ユーザーのことなのか人間のことなのかが判別しづらいため、「ヒューマンユーザー」という呼び方をしていると思いましょう。ヒューマンアイデンティティも同じ意味です。

ワークロード

ここでのワークロードとは、アプリケーションやサービス、コンポーネントのことを指します。要はヒューマンユーザー以外で AWS リソースへのアクセスを行いたい主体のことです。

例えば、AWS SDK を使用したプログラムであったりとか、EC2 インスタンスにインストールして用いる Systems Manager エージェントといったアプリケーションを指します。

AWS におけるプリンシパル

AWS の世界で実体を持たないヒューマンユーザーやワークロードは、以下のいずれかを用いて認証を行います。

• root ユーザー ^*2
• IAM エンティティ
  • IAM ユーザー
  • IAM ロール

認証が終わった後に AWS の実体として解釈され得る状態を指してプリンシパルと呼ぶことが多いです。言い換えると、リソースベースポリシーのPrincipalとして指定できるものを指してプリンシパルとすることが多いです。

リソースベースポリシーで指定できるプリンシパルは以下です。

• AWS アカウント およびルートユーザー
• IAM ロール
• ロールセッション（次項5で説明）
• IAM ユーザー
• フェデレーティッドユーザーセッション（次項5で説明）
• AWS サービス
• すべてのプリンシパル（認証していない匿名ユーザーも含む）

参考：AWS JSON ポリシーの要素: Principal - AWS Identity and Access Management

ここでは IAM グループが入っていません。先述の通り、IAM グループは認証には使用できないためです。また、AWS サービスがプリンシパルになり得ると考えた場合、AWS サービスは先述の「ワークロード」に内包されると考えたくなります（が、そのあたりの細い定義は不明です）。

結局プリンシパルって何？

プリンシパルとは、広い意味で「実行主体」と考えておくのが良さそうです。「ヒューマンユーザー」や「ワークロード」そのものを指してプリンシパルとすることもあれば、それらが認証を済ませた後の状態を指すこともあります。

「IAM プリンシパル」という表現に IAM グループが含まれることもあるので、細かいことを考え出すと混乱します。文脈を読んでいきましょう。

5. セッションプリンシパル

セッションプリンシパルとは、一時的な認証情報を用いて認証された状態のプリンシパルを指します。具体的には以下が該当します。

• Assumed Role セッション（ロールセッション）
• フェデレーテッドユーザーセッション ^*3

セッションプリンシパルは永続的に存在するものではありません。一時的な認証情報にはセッショントークンと呼ばれる時限付きの情報が含まれ、それが有効な時間でのみ存在するプリンシパルです。

IAM ロールの一時的な認証情報を用いて認証する場合、必ず Assumed Role セッションが生成されます。IAM ユーザーを対象に一時的な認証情報をリクエストすることもでき、その場合はフェデレーテッドユーザーセッションが生成されます。

フェデレーテッドユーザーセッションはそこまで利用頻度は多くありません。Assumed Role セッションのことを重点的に覚えておきましょう。

AWS アカウントをまたいだアクセス（クロスアカウントアクセス）

AWS リソースへのアクセス（AWS API 実行）を行う場合、AWS アカウントをまたぐかどうかを意識する必要があります。

ここでの「AWS アカウントをまたぐ」とは、以下が異なることを指します。

• プリンシパルが所属する AWS アカウント
• リクエストの実行先の AWS リソースが所属する AWS アカウント

基本的に、プリンシパルがアクセスできるのは自身と同じ AWS アカウントに属する AWS リソースだけです。例外的に、特別な許可を与えることによってクロスアカウントアクセスが行えるようになります。

クロスアカウントアクセスを行うには、以下の 2 パターンがあります。

• リソースベースで直接許可を与えるパターン
• IAM ロールを利用してプロキシするパターン

両者のイメージは以下です。

ここで大事な概念となるのはリソースベースポリシーです。

リソースベースポリシーとは

リソースベースポリシーとは、AWS リソースに適用するポリシーのことです。リソースベースポリシーの話をする前に、アイデンティティ（ID）ベースポリシーのことを考えます。

アイデンティティべースポリシーは、いわゆる IAM ポリシーのことです。IAM アイデンティティ（IAM ユーザー、IAM ロール、IAM グループ）にアタッチして使用します。リクエストの実行側、つまりプリンシパルに何に対してどのようなアクションを許可/拒否するかを定義するものです。

リソースベースポリシーはリクエストを実行される側のリソースに適用するポリシーです。（あまり「アタッチする」とは言いません。）リソースの目線で、誰からのどのようなアクションを許可/拒否するかを定義するものです。

先述の図では、AWS アカウント B 側の S3 バケット、IAM ロールにリソースベースポリシーを適用しています。 ^*4それぞれ、バケットポリシー、信頼ポリシーという呼ばれ方もします。

リソースベースポリシーはすべての AWS リソースに適用できるわけではありません。サービス単位でリソースベースポリシーをサポートするかどうかは以下のページから確認できるため、ここから詳細を確認するといいでしょう。

参考：IAM と連携する AWS のサービス - AWS Identity and Access Management

クロスアカウントアクセスにおけるリソースベースポリシー

AWS API を実行するプリンシパルと対象のリソースが AWS アカウントを跨いでいる場合、以下の両者で許可が必要です。

• プリンシパルのアイデンティティベースポリシー
• 対象リソースのリソースベースポリシー

図では赤色の矢印で表した部分です。

リソースベースポリシーを適用できるリソースタイプであれば、直接プリンシパルに許可を与えることができます。プリンシパル側で適切な許可があれば、クロスアカウントアクセスが成立します。

リソースベースポリシーを適用できないリソースに対してクロスアカウントアクセスを実行したい場合は、一度 IAM ロールをプロキシしてアクセスを行う必要があります。

ここで言っているプロキシとは、以下のことを指します。

1. プリンシパルが、対向の AWS アカウントにある IAM ロールを引き受ける（一時的な認証情報を取得する）
2. 対向の AWS アカウントの Assumed Role セッションとして、AWS リソースへのアクセスを行う

1のプロセスはクロスアカウントアクセスとなるため、IAM ロールのリソースベースポリシー（信頼ポリシー）でプリンシパルに対する許可が必要です。IAM ロールはプリンシパルであると同時にアクションの実行対象となるリソースでもあります。 ^*5

2のプロセスは、クロスアカウントではなく同一アカウントのアクセスとみなされます。同一アカウントアクセスの場合、以下のいずれかで許可があればアクセスは成立します。

• プリンシパルのアイデンティティベースポリシー
• 対象リソースのリソースベースポリシー

同一アカウントのアクセスにおいては改めて取り上げます。

AWS API のリクエストはどのように行われるのか

少し視点を変えて、AWS API リクエストを実行する流れを押さえておきます。

全体像のイメージは以下です。

プリンシパルであるヒューマンユーザー、ワークロードは、以下のインターフェースを利用して AWS API のリクエストを実行します。

• AWS マネジメントコンソール
• プログラムアクセス（AWS CLI や AWS SDKなど）

例えば EC2 サービスのリソースへのリクエスト（EC2 インスタンスの作成など）の場合、対応するリージョンの EC2 サービスのエンドポイントに対してリクエストを送信します。 ^*6

サービスエンドポイントに到達したリクエストは、IAM エンドポイント ^*7を通じ、同一リージョンの IAM のデータプレーンにパスされます。

IAM データプレーンにおいてリクエストが評価され、認証/認可が行われます。

余談：AWS IAM のコントロールプレーンとデータプレーン

ほとんどの AWS サービスはコントロールプレーンとデータプレーンから構成される、と先述しました。

AWS IAM もコントロールプレーンを持ちます。ただ少し特殊なのは、AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在します。IAM のサービスエンドポイントは「iam.amazonaws.com」のような形でリージョンごとに分かれていない、と先に述べたのはそれに関係します。

AWS IAM のコントロールプレーンとデータプレーンの関係性を表した図は以下です。

参考：AWS IAM のコントロールプレーンはバージニア北部リージョンにのみ存在しその設定内容は各リージョンのデータプレーンに伝播される | DevelopersIO

IAM サービスのコントロールプレーンには、IAM ユーザー、IAM ロール、IAM ポリシーといった IAM リソースが保存されています。それらのレプリカ相当が、各リージョンのデータプレーンに複製されます。データプレーンは、各リージョンで最低 3 つのアベイラビリティゾーンに分散するよう構成されています。

IAM ポリシーの変更といった IAM リソースに対する AWS リクエストは AWS IAM のコントロールプレーンに送信されます。変更が加わるとその内容が各リージョンのデータプレーンに伝播されます。

そういった仕組みもあり、IAM リソースに対する設定変更は即時に反映されることが保証されていません。（結果整合性モデル）

また、（IAM に限らず）データプレーンはコントロールプレーンに比べてシンプルな構成となっており、障害が発生しづらくなっています。コントロールプレーンとデータプレーンは独立しており、一方で発生した障害は原則もう一方には影響を及ぼしません。

稀に IAM サービスに関する障害が発生することがありますが、そのほとんどはコントロールプレーンに関するものであり、以下のような状態になることが多いです。

• IAM リソースに対する設定変更が失敗する、時間がかかる
• 既存の IAM リソースによるデータプレーンでの認証/認可は変わらず正常に実施される

AWS API リクエストの中身

話は戻って、AWS API リクエストの中身について取り上げます。

AWS API リクエストには、署名とリクエストコンテキストが含まれます。

AWS API リクエスト署名

AWS API リクエストには署名が含まれます。

AWS マネジメントコンソールや、各種プログラムアクセスを実施する際にはそれらのツールが自動で行ってくれているため、利用者が意識する機会は少ないかもしれません。

署名には、以下の情報が含まれます。

• エンドポイント仕様
• アクション
• アクションパラメータ
• 日付
• 認証情報

期間やスコープが絞られた署名が使用されることにより、よりセキュアな状態で認証が行われます。

参考：AWS API リクエストの署名 - AWS Identity and Access Management

AWS API リクエストに含まれるデータ

署名とは別に、リクエストに含まれる各種データがあります。それらはリクエストコンテキストに収集され、評価/認可が行われます。

リクエストコンテキストで評価される情報は以下です。

• アクションまたはオペレーション
• リソース
• プリンシパル
  • プリンシパルの情報
  • プリンシパルに関連づけられたポリシーの情報など
• 環境データ
  • IPアドレス
  • ユーザーエージェント
  • SSL 有効ステータス
  • 時刻　など
• リソースデータ
  • ターゲットのリソースのデータ（名称、タグなど）

これらの要素はアイデンティティベースポリシー、リソースベースポリシーといった JSON ポリシードキュメントの要素と深い関わりを持ちます。

IAM のデータプレーンでは、リクエストコンテキストに基づき評価対象となるポリシーが選定され、リクエストと突き合わせた評価が行われます。

評価の結果 AWS API リクエストが許可されれば、各種サービスのコントロールプレーンで後続の処理が行われます。

AWS IAM の評価論理

IAM データプレーンでのリクエストの評価においては、評価論理という概念が重要になります。

評価論理ではポリシータイプを意識する必要があります。AWS IAM のポリシータイプには以下があります。

• アイデンティティベースポリシー
• リソースベースポリシー
• Permissions boundary（アクセス許可の境界）
• Organizations SCP
• アクセスコントロールリスト（ACL）
• セッションポリシー

参考：IAM でのポリシーとアクセス許可 - AWS Identity and Access Management

（このうち、アクセスコントロールリストはちょっとイレギュラーな存在なので無視しましょう。ここでの ACL は S3 の ACL を意味しますが、AWS IAM ができる前から存在していて今となっては役目をほぼ終えたレガシーな存在です。今までありがとう。）

ACL 以外の 5 つのポリシータイプを整理すると以下のようになります。

ポリシータイプ	アタッチ対象	単独での許可
アイデンティティベースポリシー	IAM アイデンティティ（ユーザー/グループ/ロール）	可能
リソースベースポリシー	AWS リソース（対応したもののみ）	可能
Permissions boundary（アクセス許可の境界）	IAM エンティティ（ユーザー/ロール）	不可
Organizations SCP	Organizations OU（AWS アカウント全体）	不可
セッションポリシー	セッションプリンシパル	不可

表における「単独での許可」は、そのポリシーだけで許可を与えられるかどうかを表します。「不可」となっている 3 種のポリシーはガードレールとも呼ばれ、「単独では許可を与えないが、ここで許可がないと全体としての判定が拒否になる」という特徴を持ちます。

ポリシータイプ全体を考慮した評価論理のフローチャートは以下です。 ^*8

（20230224_27th_ISV_DiveDeepSeminar_Permissionsboundary.pdfより画像引用）

リクエストコンテキストにより評価対象のポリシーが決定され、順に評価されていきます。例えばプリンシパルが所属する AWS アカウントに Organizations SCP が適用されていればそれが評価対象になりますし、アクションの対象となるリソースにリソースベースポリシーがアタッチされていればそれも評価対象になる、といった具合です。

ひとつのポリシータイプの中で複数のポリシーが評価対象になることもあります。（例えば IAM プリンシパルに複数のアイデンティティベースポリシーがアタッチされている場合。）

評価論理を簡単にまとめると、以下の考えとなります。（箇条書きは並列を表すのではなく、上から順に評価されるさまを表していると捉えてください。）

• どれかのポリシーで拒否（Deny）が定義されていれば、最終結果は拒否（明示的な拒否）
• Organizations SCP がアタッチされており、そこで許可（Allow）がなければ最終結果は拒否（暗黙的な拒否）
• リソースベースポリシーで許可があれば最終結果は許可（※1）
• アイデンティティベースポリシーで許可がなければ最終結果は拒否（暗黙的な拒否）
• アイデンティティベースポリシーで許可があっても、以下がアタッチされていてそれらで許可がなければ最終結果は拒否（暗黙的な拒否）
  • Permissions boundary
  • セッションポリシー

---

（※1）リソースベースポリシーでの許可はややこしい性質を持っており、リソースベースポリシーのPrincipal要素で何を指定するかによって結果が変わる場合があります。

• AWS アカウント（rootユーザー）
• IAM エンティティ（IAMユーザー/ロール）
• セッションプリンシパル

AWS アカウント全体を指定して許可を与えても最終結果が許可にならないが、IAM ユーザーを指定して許可すれば最終結果が許可になる、ということが起こり得ます。覚悟しましょう。

---

評価論理の最終結果は以下のいずれかとなります。

• 暗黙的な拒否（どこでも許可がない、あるいはガードレールで許可がない）
• 明示的な拒否（指定した拒否が一番強い）
• 許可（明示的な拒否がなく、許可が与えられている）

また、ここでの評価論理フローチャートは同一アカウントアクセスを前提としています。クロスアカウントアクセスの場合、先ほど確認した通り以下の双方で許可が必要です。

• プリンシパルのアイデンティティベースポリシー
• 対象リソースのリソースベースポリシー

評価論理についてもう少し詳細を確認したい方は以下のエントリをご参照ください。

プリンシパルとして IAM ロールを用いる

最後に IAM ロールの主な用途を整理しておきます。

IAM ロールを用いて認証する場合、以下のいずれかのアクションを実行して一時的な認証情報を取得し、リクエストに含めることで実現します。

• sts:AssumeRole
• sts:AssumeRoleWithWebIdentity（OIDCプロバイダーを用いる場合）
• sts:AssumeRoleWithSAML（SAMLプロバイダーを用いる場合）

ここでのアクションのターゲットとなるリソースは IAM ロールですが、リクエストの実行先は IAM サービスではなく STS（Security Token Service）サービスとなります。

「この IAM ロールと同じ力が欲しい……！」と祈りを捧げることで、一時的にその力を使える権利が降ってくるようなイメージです。 ^*9

参考：一時的なセキュリティ認証情報のリクエスト - AWS Identity and Access Management

IAM ユーザーのスイッチロール先

ヒューマンユーザー、ワークロードには、個々に対応する IAM ユーザーを作成し割り当てることが多いです。この時に抱える課題として以下が考えられます。

• IAM ユーザーの認証情報は永続的なものであり流出した場合の被害が大きく、適用する権限を必要最小限のものにしたい
• IAM ユーザーが複数存在する場合、リソースベースポリシーのプリンシパルとしてそれぞれを許可するのが手間がかかる
• AWS リソースが複数の AWS アカウントに存在する場合、それぞれで IAM ユーザーを作成/管理するのは手間がかかる

そういった場面で IAM ロールを使用し、スイッチロール（IAM ロールに切り替える）することでより好ましい管理の仕方を実現できます。

なお、ワークロード向けには IAM ユーザーを使わず IAM ロールの認証情報を利用可能とする IAM Roles Anywhere という仕組みも用意されています。

参考：AWS ワークロード以外へのアクセスを提供する - AWS Identity and Access Management

EC2 インスタンス上のアプリケーションへの認証情報の提供

EC2 インスタンス上で稼働するワークロードに一時的な認証情報を渡したい時があります。そこで IAM ユーザーの永続的な認証情報であるアクセスキーを払い出し埋め込むのはアンチパターンです。

認証情報が流出した際のリスクが大きくなることもありますし、個別のインスタンスに埋め込むことになるため変更/管理作業が手間になります。

EC2 インスタンスにインスタンスプロファイルという IAM リソースを関連づけ、そのインスタンスプロファイルに IAM ロールを関連づけることで、インスタンス内部から一時的な認証情報にアクセスできるようになります。

EC2 サービスが IAM ロールの認証情報取得を STS サービスにリクエストし、その結果が EC2 サービスのコントロールプレーンに格納されます。EC2 サービスのデータプレーンで稼働するインスタンスから 169.254.169.254 というリンクローカルアドレスにアクセスすることでインスタンスメタデータサービス（IMDS）を通じコントロールプレーンにある認証情報を取得し、利用できます。

外部 IdP を利用したシングルサインオン先

サードパーティの外部 IdP（IDプロバイダー）を利用している場合は、その IdP ユーザーを活用できます。

IdP との連携方式に応じて、IAM リソースである OIDC プロバイダーもしくは SMAL プロバイダーを作成し、関連付けを行います。IAM ロールの信頼ポリシーでは、IAM リソースである ID プロバイダーからの AssumeRole 系のアクションを許可します。

そうすることで、外部の IdP ユーザーは、特定の IAM ロールに切り替えて AWS リソースにアクセスできるようになります。

今回は詳しく触れませんが、AWS IAM Identity Center はこれらの IDプロバイダー、IAM ロール、IAM ポリシーなどを効率的に配布する仕組みであると言えます。

AWS サービスロールもしくは AWS サービスリンクロール

AWS サービスも IAM ロールの権限を利用する場合があります。先述した EC2 インスタンスでの利用もその一種です。

AWS サービスが利用する IAM ロールは以下のいずれかに分類されます。

• AWS サービスロール：AWS リソースに関連づける形で使用する
• AWS サービスリンクロール：AWS サービス全体にリンクする形で使用する

前者の AWS サービスロールは、個々のリソースに関連づけて使用します。例えば RDS サービスの DB インスタンスで詳細モニタリングという機能の有効化が必要な場合、RDS サービス用ロールを関連づけ、必要な権限を提供します。

EC2 インスタンスのインスタンスプロファイルに関連づける IAM ロールも AWS サービスロールです。

後者の AWS サービスリンクロールはサービスにリンクされたロール（service-linked role、SLR）とも呼ばれ、個々のリソースで関連付けの有無を決定するものではありません。

例えば RDS の DB インスタンスや ELB サービスの ALB を作成/稼働させる場合、それらのリソース用の ENI（ネットワークインターフェース）が必要となります。ここでの ENI は動的に作成/削除されます。ENI は EC2 サービスに属するリソースで、その操作には当然権限が必要となります。

ここで必要な権限が AWS サービスリンクロールによって賄われます。例えばロードバランサーに AWS サービスロールを関連づけてそこで ENI の作成/削除権限を持たせるとなった場合、関連付けを忘れるとロードバランサーの作成が失敗するということになりかねません。

大雑把に、個々のリソースで要否が変わりうるものは AWS サービスロール、そうでないものは AWS サービスリンクロール、と覚えておくと実態に合っていることが多いでしょう。

終わりに

今回は AWS IAM についてまとめてみました。技術的なことというよりは、その裏側の仕組みを改めておさらいしてみる、という属性が強かったかなと思います。

AWS IAM というサービスは AWS を利用する上で避けられないサービスですので、全体像の理解につながっていれば幸いです。

以上、千葉 幸宏（チバユキ）による『AWS 入門ブログリレー 2024』の32日目のエントリ『AWS IAM』編でした。

次回、2024/04/26 は弊社 千葉 幸宏（チバユキ） による「AWS IAM Access Analyzer編」の予定です！

参考

• AWS の API を理解しよう ! ~ 初級編 : API の仕組みと利用方法を理解しよう - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
• AWS再入門ブログリレー2022 AWS IAM編 | DevelopersIO
• IAM とは - AWS Identity and Access Management
• AWS Black Belt Online Seminar AWS IAM

脚注